📚 Week 3 · Unit II · Lecture 9
CAMS — Culture &
Automation; TDD

Going back to the foundations: why DevOps starts with people, not pipelines — and how Test-Driven Development builds quality in from the very first line of code.

Dr. Mohsin Furkh DarSchool of Computer Sciences
DateTue, 23 Jun 2026 · 9:00 – 10:00 AM
ProgrammeBTech CSE – 5th / 6th Semester
Today's Agenda
1
Recap — CI/CD & the Maturity Ladder
2
CAMS Revisited — Why We Return to Culture
3
Culture — Blameless, Collaborative, Shared Ownership
4
Automation — What, Why, and What NOT to Automate
5
Test-Driven Development (TDD) — Red, Green, Refactor
6
TDD in Practice — Benefits, Pitfalls & a Worked Example
Recap
Where We Left Off
✅
Lecture 8: We studied Continuous Integration (frequent, tested merges) and Continuous Delivery (always-releasable builds), along with the CI/CD maturity ladder: No Automation → CI → Continuous Delivery → Continuous Deployment.
🎯
Today: CI/CD pipelines are automation — but automation alone doesn't make DevOps work. We return to the first letter of CAMS — Culture — and pair it with Automation, then connect both to a concrete engineering practice: Test-Driven Development (TDD).
Quick Reminder: CAMS
  • Culture — people & mindset
  • Automation — tools & pipelines
  • Measurement — metrics & data
  • Sharing — knowledge & feedback
Why C and A Together Today
  • Automation without the right culture creates resentment, not adoption
  • Culture without automation stays a nice idea with no teeth
  • TDD is where both meet — a cultural discipline, enacted through automated tests
Foundations
Why Culture Comes Before Tools
🎭
Culture is the "C" in CAMS — and it's deliberately listed first. You can buy every CI/CD tool on the market and still fail at DevOps if teams don't trust each other, hide failures, or refuse to share ownership of production.

You can't buy DevOps — it's not a product on a shelf. DevOps is a culture, and tools merely amplify the culture that's already there, good or bad.

— Common DevOps community wisdom
🛠️
Tools Amplify, Not Create
A great CI/CD pipeline in a blame-driven team just automates the speed at which failures get pinned on someone.
🤝
Trust Enables Speed
Teams that trust each other ship faster — they spend less time on defensive documentation, sign-offs, and CYA processes.
🌱
Culture Is Learnable
Unlike personality, team culture is a set of practiced behaviors — blameless retros, shared on-call, open communication — that can be deliberately built.
Culture Deep Dive
Building a Blameless, Collaborative Culture

DevOps culture rests on a few concrete, practiced behaviors — not vague slogans about "teamwork."

🔥 Blame Culture (Avoid)
  • "Who broke the build?" as the first question after an incident
  • Developers hide mistakes out of fear
  • Postmortems become trials, not learning sessions
  • Ops and Dev blame each other for outages
  • People stop raising risks early to avoid being blamed later
✅ Blameless Culture (Build)
  • "What in our system allowed this to happen?" replaces "who did this?"
  • Mistakes are treated as data, not character flaws
  • Postmortems focus on process fixes, shared openly
  • Dev and Ops share on-call and incident response
  • Psychological safety lets people flag problems early
💡
Key Insight: Blameless does not mean consequence-free. It means the team's first instinct after a failure is to fix the system, not punish the person — because punishing people for honest mistakes just teaches everyone to hide them next time.
Framework
Gene Kim's "Three Ways" of DevOps

From The Phoenix Project, these three principles describe the cultural and technical foundation of DevOps thinking.

1
The First Way — Flow
Optimize the entire system, not just one team's part of it. Work should flow left-to-right (Dev → Ops → Customer) fast, visibly, and without being thrown "over the wall."
2
The Second Way — Feedback
Create fast, constant feedback loops right-to-left (Customer → Ops → Dev) so problems are caught and fixed as close to their source as possible.
3
The Third Way — Continuous Learning
Build a culture that encourages experimentation, takes risks, and learns from failure through repetition and practice — turning every incident into organizational knowledge.
📌
Connecting back: CI/CD (Lecture 8) is the technical engine of "Flow." Monitoring and metrics support "Feedback." Blameless postmortems and TDD support "Continuous Learning." Culture and tools work as one system.
Pillar Deep Dive
Automation — The "A" in CAMS
🤖
Automation means removing manual, repetitive human steps from the software delivery process — replacing them with reliable, repeatable, machine-executed processes.
🔁
Consistency
A script runs the exact same way every time. A human, even a careful one, introduces variation and occasional error.
⚡
Speed
Automated tasks (builds, tests, deployments) run in minutes — tasks that might take a human hours to do manually and correctly.
🧠
Frees Human Judgment
Automating routine work frees engineers to focus on creative problem-solving, architecture, and decisions that actually need human judgment.
🔗
Connecting to Lecture 8: CI/CD pipelines (Jenkins, GitHub Actions) are Automation in action. Today we ask the deeper question: what should we automate, and what should we deliberately keep human?
Decision Framework
What to Automate (and What Not To)
Area Automate? Why
Code Builds & Compilation ✅ Always Mechanical, repetitive, zero judgment required
Unit / Integration Testing ✅ Always Must run identically and instantly on every change
Infrastructure Provisioning ✅ Mostly (IaC) Consistency across environments; avoids "snowflake servers"
Routine Deployments ✅ Mostly Reduces human error and deployment fatigue
Production Release Decision ⚠️ Context-dependent Business risk tolerance decides Delivery vs Deployment
Incident Root-Cause Analysis ❌ Keep Human Requires judgment, context, and creative diagnosis
Architecture & Design Decisions ❌ Keep Human Requires understanding trade-offs unique to the business
⚠️
Common Mistake — "Automating Chaos": Automating a broken, undocumented manual process just makes it fail faster and more consistently. Fix and standardize the process first, then automate it.
Synthesis
How Culture and Automation Reinforce Each Other
Culture Enables Good Automation
  • Trust lets teams automate deployments without fear of being blamed for failures
  • Shared ownership means everyone maintains the automation, not just one "DevOps person"
  • Psychological safety lets engineers admit when automation itself is broken
Automation Reinforces Good Culture
  • Removes the human bottleneck that often becomes a blame target
  • Makes processes transparent and visible to the whole team — no tribal knowledge
  • Frees time for collaboration instead of repetitive manual toil
🎯 Bottom Line

Culture and Automation are not sequential steps — they are a feedback loop. Good culture makes teams willing to invest in automation; good automation removes the friction and blame that erode culture. CAMS works because its pillars reinforce one another.

New Topic
What Is Test-Driven Development (TDD)?

Test-Driven Development is a software practice where you write the test before you write the code that makes it pass — letting tests drive the design of your implementation.

— Kent Beck, creator of TDD & Extreme Programming (XP)
📝
Test First, Code Second
You write a failing automated test that describes the behavior you want, before any implementation exists.
🎯
Design by Intent
Writing the test first forces you to think about the interface and expected behavior before getting lost in implementation details.
🔗
The Cultural Link
TDD is where Culture meets Automation: a disciplined team habit (Culture), enforced through automated test suites (Automation) that feed directly into CI (Lecture 8).
Core Cycle
The Red–Green–Refactor Cycle

TDD follows a short, disciplined, repeating cycle — typically just minutes long per iteration.

🔴
RED
Write a failing test for behavior that doesn't exist yet
→
🟢
GREEN
Write the simplest code that makes the test pass
→
🔵
REFACTOR
Clean up the code while keeping all tests passing
↻
🔴
Red — Write a Failing Test
Write the smallest possible test for a new piece of behavior. Run it — it should fail (since the code doesn't exist yet). This confirms the test is actually testing something.
🟢
Green — Make It Pass
Write the minimum amount of code needed to make the test pass — no more. Don't worry about elegance yet; just get to green.
🔵
Refactor — Clean It Up
Now improve the code's structure, naming, and design — removing duplication — while continuously re-running tests to ensure nothing breaks.
Worked Example
TDD in Practice: A Simple Calculator Function

Goal: implement an add(a, b) function using TDD.

// STEP 1 — RED: write a failing test first test('add(2, 3) should return 5', () => { expect(add(2, 3)).toBe(5); // ❌ fails: add() doesn't exist });
// STEP 2 — GREEN: simplest code to pass function add(a, b) { return 5; // ✅ passes (hacky, but valid for now!) }
// STEP 2b — add a 2nd test to force a real implementation test('add(10, 15) should return 25', () => { expect(add(10, 15)).toBe(25); // ❌ fails with hardcoded "5" }); // STEP 3 — REFACTOR: write the real, general implementation function add(a, b) { return a + b; // ✅ both tests now pass }
💡
Why the hardcoded "5" matters: It looks silly, but it illustrates TDD's discipline — write only enough code to pass the current test. A second, different test then forces you toward a genuinely correct, general solution.
Trade-offs
Benefits and Pitfalls of TDD
✅ Benefits
  • Built-in regression test suite — refactor fearlessly later
  • Forces clear thinking about requirements before coding
  • Naturally produces loosely-coupled, testable code
  • Feeds directly into CI pipelines (Lecture 8) — tests already exist for every commit
  • Serves as living documentation of expected behavior
⚠️ Pitfalls
  • Steep learning curve — takes practice to "think in tests"
  • Slower initial velocity while the habit is being built
  • Poorly-written tests can become brittle and slow teams down
  • Not well-suited to exploratory/throwaway prototyping code
  • Requires team-wide discipline — one developer skipping it weakens the whole suite
📌
Where TDD fits in CAMS: TDD is a cultural habit (discipline, team agreement) made real through automation (the test suite that runs in CI). It directly produces the "self-testing build" practice we discussed in Lecture 8.
Clarifications
Common Misconceptions
❌
"TDD means writing all tests upfront, then all code" — False. TDD is a tight, iterative micro-cycle — one small test, then one small piece of code, repeated continuously, not a big upfront test-writing phase.
❌
"DevOps culture means no accountability" — False. Blameless culture means focusing on systemic fixes over personal blame — it does not mean ignoring repeated negligence or skipping retrospectives.
❌
"Automate everything, as fast as possible" — False. Automating a broken or undocumented process just produces broken results faster. Standardize first, then automate.
✅
Good Practice: Build psychological safety and shared ownership (Culture), automate consistent and well-understood processes (Automation), and use TDD's Red-Green-Refactor cycle to bake quality into code from the start.
Lecture Summary
Key Takeaways

Lecture 9 — CAMS: Culture & Automation; Test-Driven Development

1
Culture Comes FirstTools amplify culture, good or bad. DevOps tooling fails without trust, shared ownership, and blameless practices.
2
Blameless ≠ Consequence-FreeFocus first on fixing the system, not punishing the person — this is what makes early problem-reporting safe.
3
Gene Kim's Three WaysFlow, Feedback, and Continuous Learning describe the cultural-technical foundation of DevOps thinking.
4
Automate DeliberatelyAutomate consistent, well-understood processes. Keep judgment-heavy work — root cause analysis, architecture — human.
5
TDD: Red–Green–RefactorWrite a failing test, write minimal code to pass it, then refactor — repeating in short, disciplined cycles.
6
TDD = Culture + AutomationA disciplined team habit, enforced by an automated test suite that plugs directly into CI pipelines.
📚 Next Lecture

Lecture 10 (Mon, 29 Jun): CAMS — Measurement & Sharing; Configuration Management — We'll complete the CAMS framework with Measurement and Sharing, then introduce Configuration Management as the next building block of DevOps automation.

Dr. Mohsin Furkh Dar · School of Computer Sciences · UPES Dehradun

CSDV3016P / CSDV3017 · DevOps Overview · Summer 2026